IBIS Macromodel Task Group Meeting date: 25 Sep 2012 Members (asterisk for those attending): Agilent: Fangyi Rao Radek Biernacki Altera: David Banas Julia Liu Hazlina Ramly Andrew Joy Consulting: Andy Joy ANSYS: Samuel Mertens * Dan Dvorscak * Curtis Clark Steve Pytel Luis Armenta Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Feras Al-Hawari Cavium Networks: Johann Nittmann Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: * Michael Mirmak Maxim Integrated Products: Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff Justin Butterfield NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: Eckhard Lenski QLogic Corp. * James Zhou Sigrity: Brad Brim * Kumar Keshavan Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns * Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla Ray Anderson The meeting was led by Arpad Muranyi ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Walter send updated BIRD 123.4 for posting - Done - Walter send updated BIRD 150.1 for posting - Done - Walter also sent a BIRD 121 update ------------- New Discussion: Michael M. reported on the last interconnect meeting: - They discussed the overall structure of IBIS - Deprecation vs. creating a new specification will be discussed next meeting Walter showed BIRD 123.4 draft 3: - Walter: David Banas asked me to add some text - This is about when Rx_Clock_Recovery_Dj could be used - It doesn't seem necessary, but I don't object - Arpad asked all to comment on this - Michael M.: Dj always breaks down to those two components? - Walter: I don't think so - Mike L.: It could be stated as an example, to not be construed as a limitation. - Walter: David also wanted a line removed, not sure if it should be Ambrish showed BIRD 147 draft 1: - Ambrish: This is still in plain text format, not the new IBIS 5.1 format - The new Type "Bits" has been added - The new Format "Bit_Pattern" has been added - These begin with letter codes b,o,h,d for number format - Walter: Why would we want to have decimal format? - Type Bits would not be able to wrap across multiple lines - An advantage of strings is being able to use multiple lines - Ambrish: PRBS would also use Type Bits - Same for LFSR, except this one is a bit tricky - Commas are used to separate register taps - Kumar: Does it have a starting seed? - Ambrish: Yes - Ambrish: Without these types we would have to provide a lot of string use definitions - Kumar: Are any standards committees involved with this? - Ambrish: We need to discuss that - Walter: Do we really need both PRBS and LFSR? - Kumar: IEEE discusses both, but LFSR is a way to do PRBS - LFSR can be used for other things - Walter: LFSR guarantees consistent implementation - PRBS may not be consistent - Ambrish: Even with a seed? - Kumar: You have to be more specific - Walter: We could eliminate PRBS and show how to use LFSR for PRBS7, etc. Michael M.: Is BIRD 131 to be discussed soon? - Arpad: It may not be for a while but it is on the list Walter showed BIRD 150.1 draft 1: - Walter: The text is the same but it uses the new IBIS 5.1 format - The template didn't work well for this - We should all review this against BIRD 150.1 to check for mistakes - Arpad: The new definitions at the bottom might be better placed elsewhere - Walter: Good idea - Walter explained the need for the various definitions - Arpad: These are AMI related reserved names - Maybe they should be in the AMI section - Walter: Agree - I call these "predefined" but they could be Reserved Walter showed BIRD 127.2 draft 3: - Walter: This is also in IBIS 5.1 format - The format worked out better for this one - We have been discussing by email whether to use List or Table - I agreed with Arpad, and changed it to Table - My example has one column, lots of rows - Walter: DLL_Path is needed because the DLL can't find out where it is - It can also be used to find things like Matlab runtime files - The EDA tool will have to handle various path types - The example needs to be cleaned up - Walter: DLL_ID will help avoid name collisions - Arpad: Does the DLL have to know the directory structure for it's files? - Walter: Yes - For example some vendors supply files that the DLL knows how to find - Arpad: We might need more parameters to handle all possible cases - For example regular files and executables might need to be separate - Users might want to have only one copy of shared libraries - Walter: A Model_Specific parameter might be used for that - To keep library items elsewhere a symbolic link in the DLL directory might do - Arpad: Users might end up editing AMI files - That would not be good - Greg might have input on this - Greg: I haven't run into issues - Walter: Environment variables can serve some purposes too - James: You can't point to an executable through environment variables - Matlab DLLs have trouble finding the right runtime version - We need a clear designation of where supporting files can be - For example files might be in the same directory or sub-directories - Arpad: The spec should say DLLs should not depend on CWD - Mike L: DLL_Path and Supporting_Files should work together - The Supporting_Files table could indicate where the DLL wants to find the files - Arpad: We might not need Supporting_Files - Walter: A directory might contain multiple models - We need to know which ones to take - Walter added a note to clarify this - Greg: There are two locations: - Where the model is - Where the DLL is - Walter: No the DLL has to be where the IBIS files is - But the DLL has no way on it's own to find out where that is - Arpad: We should all continue comments on this online ------------- Next meeting: 02 Oct 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives